The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have found their way into just about every aspect of the American lifestyle. One reason for this proliferation is the ability of computer systems to perform a variety of tasks in an efficient manner. The mechanisms used by computer systems to perform these tasks are called computer programs.
Like computer systems themselves, the development of computer programs has evolved over the years. The EDVAC system used what was called a "one address" computer programming language. This language allowed for only the most rudimentary computer programs. By the 1960s, improvements in computer programming languages led to computer programs that were so large and complex that it was difficult to manage and control their development and maintenance.
Therefore, the focus of the 1970s was on developing programming methodologies and environments that could better accommodate the increasing complexity and cost of large computer programs. One such methodology is called Object Oriented Programming (OOP). Though it has been some time since the fundamental notions of OOP were first developed, OOP systems are becoming more and more prevalent because it is felt that use of OOP can greatly increase the efficiency of computer programmers. Not surprisingly, objects are central to OOP technology. A single object represents an individual operation or a group of operations that are performed by a computer system upon information controlled by the object. Objects can be thought of as autonomous agents that work together to perform certain tasks. Sometimes entire computer programs are made up of groupings of objects and sometimes objects are simply accessed by more traditional computer programs to perform one specific task or subtask. For a general background regarding objects and object-oriented programming, see Grady Booch, Object Oriented Design with Applications, (Benjamin/Cummings Publishing Co. 1991), and the Overview section herein.
While the use of OOP has led to greater programmer efficiency, that same use brings with it several challenges that have yet to be overcome by prior art mechanisms. One such challenge is handling objects that are persistent and shareable. An object is persistent if the object has a lifetime independent of its users. An object is shareable if there exists a mechanism for allowing multiple users to access one or more of the object's methods. An object is secure if users are unable to access the object unless they have sufficient authority. When objects are persistent and shareable and secure, access to methods on these objects must be controlled using authorization checks and locking mechanisms. Authorization checking assures that the user calling the method is authorized to access the object, while locking assures that users may not interfere with one another when accessing the same object. For purposes of the discussion herein, a "user" of a method is any client process that accesses (or calls) a method within an object. A client process (or user) that calls a method of a server object may be another object (e.g., in the case of OOP), or may be any other suitable client program that calls the method.
Known solutions to authorization checking and locking are unsatisfactory for a number of reasons. One known solution is to require that the programmer write code to determine/set the authorization of an object and to check its authorization and to obtain a lock of the object. This scheme effectively gives a programmer the power to decide if the client program is authorized to access the method. Putting this power and responsibility in the programmer's hands requires that the programmer follow strict rules in programming, which may be intentionally or inadvertently violated by the programmer. In addition, the extra code required for the authorization checking and locking functions substantially degrades the performance of the computer program, increases its size, and increases the complexity of the program. This user-driven scheme of authorization checking and locking is only as good as the programmer using it, and the ease with which it may be ignored or violated along with the run-time penalty makes it an undesirable solution. Without a mechanism for automatically performing authorization checks and locking functions when a method on a persistent, shareable object is called, the efficiency and security of computer programs will be impaired, resulting in less than optimal performance from computers running these computer programs.